allow mutating function args through &raw const#111517
allow mutating function args through &raw const#111517bors merged 2 commits intorust-lang:masterfrom
&raw const#111517Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
lukas-code
force-pushed
the
addr-of-mutate
branch
from
a1e0d5f to
9c418e5
Compare
|
Opsem can help analyze whether an opt is correct, but at least I lack the experience to actually review their implementations. r? mir-opt |
|
Thanks. @bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (3603a84): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 660.495s -> 659.942s (-0.08%) |
| // Whether mutating though a `&raw const` is allowed is still undecided, so we | ||
| // disable any sketchy `readonly` optimizations for now. | ||
| // But we only need to do this if the pointer would point into the argument. | ||
| !place.is_indirect() |
There was a problem hiding this comment.
Why is it okay to consider indirect places immutable? I have no idea what kind of code this affects, but it seems very suspicious to me that whether or not the place is indirect would make any difference.
There was a problem hiding this comment.
If you have
fn foo(arg: *const u8) { /* ... */ }then addr_of!(*arg) can't change the value of arg, only addr_of!(arg) can.
In practice, this doesn't actually make a difference and we could always return true here, because currently
- single pointers are never passed indirectly
- when accessing a pointer in a compound type, e.g.
addr_of!(*(arg.ptr))this operation is split in two mir statementslet tmp = deref_copy arg.ptrand&raw const *tmpand so this&raw constalready doesn't affect whetherargis readonly.
There was a problem hiding this comment.
then addr_of!(*arg) can't change the value of arg, only addr_of!(arg) can.
This should apply uniformly to &[raw] [mut|const] (including regular non-raw borrows) then, right?
There was a problem hiding this comment.
That seems to be correct. In that case I'd probably just remove the special case here (and just return true) rather than introduce more special casing, because it doesn't actually matter.
7 participants
Fixes #111502 by "turning off the sketchy optimization while we figure out if this is ok", like @JakobDegen said.
The first commit in this PR removes some suspicious looking logic from the same method, but should have no functional changes, since it doesn't modify the
contextoutside of the method. Best reviewed commit by commit.r? opsem